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PDS  Functional  Capabilities 
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Conclusions 

.  The  use  of  ECSAM  and  STATEMATE  with  massive 
in-house  methodological  support  served  as  a  strong 
catalyst  In  the  creation  of  requirements  specifications 
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Ahatract^ 

ECSAM  is  a  comprehensive  object-based  model 
driven  method  for  the  anatyns  and  moiling  of  Computer 
Based  Systems  (CBS)  and  their  software.  It  was  developed 
at  the  Israel  Aircrefl  Industries  (lAI)  for  the  analysis  and 
design  of  complex  embedded  computer  systems  and  their 
stfcware.  Using  tMs  method  systems  are  described  by  two 
complementary  models:  a  conceptual  model  and  a  design 
model.  The  conceptual  model. describes  a  system  in  terms 
of  its  conceptual  structure  and  interfaces,  its  capabilities 
and  its  dynarde  behavior.  The  design  model  describes  the 
systems  in  terms  of  its  architecture,  hardware  and  software 
subsystems,  communication  channels  and  their  properties, 
the  human  •  machitu  interface  design  and  implementation 
constrants. 

ECSAM  relies  on  graphical  representations  of  ail  its 
views.  It  uses  formed  setruuitics  wherever  applicable  thus 
allowing  the  testing  of  the  systems'  static  specification 
and  the  simulation  ^  its  dynamic  behavior. 

ECSAM  is  used  for  the  static  and  dynamic  analysis  of 
complex  embedded  computer  systems.  It  is  applicable  to 
simple,  single  computer  systems  as  well  as  to  complex 
multi-systems  and  their  software.  It  has  been  developed 
since  existing  methods  have  not  addressed  sati^actorily 
the  development  needs  of  modem  CBS  at  lAI. 

The  method  has  been  developed  since  1980  answering 
the  needs  of  lAI  projects.  The  evolving  versions  of 
ECSAM  have  been  taught  over  the  years  to  several 
hundred  system  and  software  engineers.  Currently  the 
method  is  being  successfully  used  by  many  projects.  The 
method  is  supported  by  the  STATEMATE  CASE  tool 

The  paper  describes  the  ECSAM  conceptual  model, 
outlines  the  characteristics  of  the  design  model  and  the 
mapping  between  the  two  models,  and  bri^y  outlines  the 
lAI  experience  in  the  methods  use. 


^  The  paper  was  submitted  to  the  ICSE 16  conference 
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Systems. 

1.  intriMiBctiQB 

Idiodem  Computer  Based  Systems  (CBS),  particulaily 
embedded  computer  systems,  are  often  very  complex. 
Many  of  them  are  hierarchical  multilevel  systems  that 
contain  many  computers  in  each  level.  Others  are 
composed  of  many  loosely  coupled  cooperating 
subsystems.  Frequently,  each  of  these  subsyWms  is 
large  and  complex  by  itself,  and  is  implemented  as  a 
multilevel  multicomputer  system.  As  a  typical  example 
we  may  take  a  modem  integrated  avionics  system,  which 
is  composed  of  many  subsystems,  e.g.  navigation,  radar 
and  electronic  warfare  systms.  Each  of  these  subsystems 
typically  is  a  mnlticomputBr  system.  Most  of  them  react 
dynami^y  to  random  exterrud  signals  and  sequences  of 
external  events.  Their  dynamic  behavior  also  dqrends  on 
the  operational  history  of  the  systems  and  on  complex 
logic  conditions. 

Specification  languages  and  analysis  methods 
a{^li(^le  to  such  systems  should  allow  the  development 
of  coherent,  precise  modds  of  the  systems  being  analyzed 
and  specified.  They  should  consider  the  static 
characteristics  and  the  djrnamic  behavior  rtf  the  systems, 
thmr  multisystem  and  multilevel  characteristics  arxl  the 
relevant  design  issues.  The  methods  should  use  "fonnal” 
graqrhical  rqiresentations  of  the  system  models,  based  on 
well-defined  semantics,  to  achieve  clarity,  precision,  and 
testaUIity.  The  methods  should  allow  a  st^wise  itmadve 
analysis,  design  and  implementation  of  the  systems  and 
their  software  and  should  be  teachable  to  a  wide  spectrum 
of  systems  and  software  enginsers. 


Many  methods  for  the  description,  analysis  and 
specification  of  computer  based  systems  and  their  software 
are  known  in  the  literature  [e.g.  ALF08S,  ASCE89. 
HATL87.  HENI80,  ROSS85,  RUMB91.  WARD86. 
ZAVE84j.  Previously,  the  majority  of  the  methods 
supported  only  the  static  analysis  of  systems,  such  as 
functional  decomposition  or  data  flow  techniques.  Others 
related  to  problems  associated  with  the  dynamic  behavior 
of  systems  and  software.  Very  few  relate  to  the  analysis 
and  specification  of  entire  computer  based  systems  and 
their  software.  Only  few  of  the  object-oriented  software 
analysis  and  design  methods  published  in  recent  years 
address  the  static  and  dynamic  aspects  of  software 
[BOOC91.  RUMB91].  Methods  addressing  software, 
however,  usually  disregard  system  aspects,  and  treat 
software  as  if  it  existed  in  ‘Vacuum”. 

This  paper  describes  ECSAM,  an  Embedded 
Computer  Systems  and  Software  Analysis  and  Modeling 
method.  Using  this  method  a  model  of  the  system  to  be 
developed  is  built  following  an  orderly  process  obeying  a 
well  defined  set  of  rules.  The  essential  idea  behind 
ECSAM  is  that  the  driving  force  behind  the  development 
process  is  the  construction  of  coherent  models  that 
represent  the  problem  and  solution  spaces  of  the  desired 
system.  The  model  of  the  problem  space  is  called  a 
'^conceptual  model”,  while  the  solution  space  model  is 
called  a  "design  modd”. 

ECSAM.  an  Object-Based  method  [BOOC911, 
supports  the  analysis  of  entire  Computer  Based  Systems 
as  well  as  the  analysis  of  software  systems  and  modules. 
It  addresses  the  issues  of  multi-level  systems  and  multi¬ 
systems,  a  capability  not  adequately  addressed  in  other 
methods  [DAVI90]..  ECSAM  is  especially  suitable  for 
the  aiuilysis  of  embedded  systems  such  as  process  control 
systems,  avionics  systems,  military  systems,  medical 
instruments  and  modem  consumer  electronic  systems.  It 
is  particularly  well-suited  for  software  design  intended  for 
implementation  in  Ada  language,  which  has  been 
successfully  demonstrated  in  several  projects.  Graphic 
techniques  are  used  to  produce  the  models  and  to  represent 
their  views.  ECSAM  provides  guidelines  for  the 
exploitation  of  graphical  representation  that  provide  a 
simplified  initial  view  of  a  complex  system.  As  the 
system  concepts  mature  and  stabilize,  the  representation 
evolves  in  a  way  that  promotes  incremental  increase  of  the 
depth  of  understanding  of  the  system  specification. 

ECSAM  is  being  developed,  by  the  authors  at  the 
Israel  Aircraft  Industries  (lAl)  since  1980  [LAVI84, 
LAVI86,  LAV881,  LAV882,  LAVI89,  LAVI91, 
LAV921,  KUDI92.  WINO90,  WIN091].  Initially  the 
efforts  were  concentrated  on  analysis  of  the  software  of 
embedded  computer  systems.  Later  on,  while  working  on 
multicomputer  systems,  die  scope  was  extended  to  address 
the  engineering  of  systems  as  well  as  their  software. 
Recently  it  was  further  extended  to  address  the 
development  of  multisystems  and  to  the  analysis  of  the 
systems'  external  dynamic  behavior.  The  meth^  is  being 


augmented  and  improved  continuously  based  on  practical 
experience  gained  during  its  application  to  projects  within 
lAJ.  The  ECSAM  development  was  the  basis  for  the 
development  of  STATEMATE  IHARE901.  a  CAS^E  ‘ 
tool  used  in  conjunction  with  the  method  at  lAl. 
ECSAM  has  proven  useful  to  engineers  in  organizing 
their  thoughts  and  expressing  them  in  an  explicit  and  clear 
way  thus  improving  considerably  the  analysis  process  and 
the  quality  of  the  specifications  of  computer  based 
systems.  ^SAM  has  been  taught  during  recent  years  to 
several  hundred  system  and  software  engineers.  The 
method  and  the  supporting  tool  STATEMATE  are  being 
used  successfully  in  many  projects  within  lAI. 

This  paper  consolidates  ideas  publi^ed  in  previous 
ECSAM  papers  and  new  unpublished  work  done  during 
the  past  ttiTM  years.  It  focuses  on  the  ECSAM  modeling 
approach.  It  describes  the  ECSAM  conceptual  and  design 
models  and  their  views,  the  generic  model  of  embedtM 
computer  systems,  the  development  of  multilevel  and 
multisystem  models  and  basic  concepts  of  the  mapping 
between  the  conceptual  and  the  design  models.  It 
summarizes  the  experience  of  applying  ECSAM  in 
projects  at  lAI  and  concludes  with  a  short  discussion 
comparing  the  ECSAM  model  with  other  known  CBS 
analysis  models. 

2.  The  ECSAM  Modeling  Approach 

The  development  of  engineering  artifacts  typically 
requires  two  augmenting  complementary  models:  a 
conceptual  model  and  a  design  model  [JACK92,  LAV193]. 
The  conceptual  model  which  describes  the  system  in  the 
problem  space  is  necessary  for  the  understanding  of  the 
physical  phenomena  on  which  the  system  is  based.  Its 
main  purpose  is  to  support  the  behavioral  and  performance 
amilyses  of  the  systems.  The  design  model  describes  the 
system  in  the  solution  space.  It  represents  the  actual 
structure  of  the  system  and  supports  its  design  process. 

The  ECSAM  modeling  approach  addresses  the 
conceptual  and  the  design  models  and  defines  the  m^ing 
between  them.  As  will  be  discussed  later,  the  concqitual 
model  can  describe  a  family  (class)  of  systems  which  can 
be  mapped  to  different  architectures  with  similar 
functionality  depending  on  implementation  constraints. 
Both  models  are  used  concurrenUy  to  analyze  and  engineer 
the  System  Under  Development  (SUD). 

According  to  Figure  1,  ECSAM  can  be  viewed  as  a 
prism,  resolving  the  system  specification  into  two  models 
-  the  design  and  the  conceptual  ones,  further  resolving  the 
conceptual  model  into  interrelated  views. 

Due  to  the  complexity  of  embedded  computer  systems 
it  is  impossible  to  describe  their  conceptual  models  by  a 
single  view.  Instead,  it  is  necessary  to  separate  concerns 
during  the  system  analysis  process  and  utilize  different 
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Figure  1  -  ECSAM  Model  components 


related  modeling  views  to  describe  the  static  and  dynamic 
aspects  of  the  system,  as  shown  in  Figure  1. 

3.  The  ECSAM  Conceptual  Model 

The  ECSAM  conceptual  model  is  described  by  the 
following  three  views: 

•  The  Logical  Modules  View,  which  describes: 

The  partitioning  of  the  system  into  its 
logical  subsystems 

The  external  information  that  flows  between 
the  system  and  its  environment 
The  information  that  flows  between  the 
internal  subsystems 

The  functional  capabilities  (activities) 
petfomied  by  each  logical  subsystem. 

•  The  Operating  Modes  View  which  describes  the 
system’s  main  operating  modes  and  the  transitions 
between  ttem. 

•  The  Dynamic  Processes  View  which  describes 
the  behavioral  ^ocesses  that  occur  in  the  system  in 
its  various  operating  modes  in  response  to  external  or 
internal  events. 

The  overall  dynamic  behavior  of  the  systems  is 
jointly  described  by  the  last  two  views. 

The  three  views  ate  complementary  and  interrelated, 
just  like  views  used  in  the  drafting  of  mechanical  artifacts. 


During  the  systems  analysis  we  iteratively  examine  the 
different  views  assuring  mutual  consistency  and 
completeness  of  the  model  and  of  the  resulting 
specdkations. 

The  ECSAM  views  and  concepu  discussed  in  the 
following  sections  are  demonstrated  using  a  simplified 
naval  anti-missile  point  defense  system  (MPDS)  as  an 
example.  The  MPDS  is  used  for  the  detection  of 
attacking  missiles  and  defense  against  them. 

This  chi^tter  first  presents  each  of  the  conceptual 
model  views  and  then  the  relationships  between  the  views. 


This  view  describes  the  partitioning  of  the  system 
into  logical  modules  or  subsystems,  information  flows, 
and  functional  capabilities  performed  by  each  of  the 
subsystems.  The  logical  modules  can  be  viewed  as 
abstract  ((»’  virtual)  machines  used  as  building  blocks  in 
the  modeling  process.  Logical  modules  arj 
implementation  independent  Their  capabilities  can  be 
allocated  to  hardware,  software,  manual  operations  or  a 
mixture  of  all  three.  As  will  be  discuss^  later,  their 
c^abilities  may  even  be  allocated  to  various  architectural 
modules  due  to  implementation  constraints. 
definition  follows  the  information  hiding  cont^^ 
described  by  Pamas  [PARN86].  At  the  pure  software 
level,  ECSAM’s  logi^  modules  are  abstract  data-types 
that  have  internal  slates  and  data  structures.  The  common 
interpretation  (or  rather  implementation)  of  logical 
modules  in  Ada  are  packages. 
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MPDS 

•  Hostile.Targets  •  Targets  classified 
by  the  system  as  hostile 

Environmental  systems  may  send 
signals  (messages)  to  the  system,  receive 
signals  from  it,  or  do  both.  In  the  latter 
case  the  environmental  systems  are  (hawn 
twice  -  to  the  left  of  the  system  (as 
sources),  and  to  its  right  (as  sinks).  This 
simplifies  the  drawings,  and  their 
comprehension  and  analysis. 

The  MPDS  can  be  decomposed  into 
the  following  logical  subsystems: 


Figure  2  -  MPDS  Logical  Modules 

A  diagram  of  the  MPDS  logical  modules  view  is 
shown  in  Figure  2.  In  this  diagram,  the  system,  its 
external  (environmental)  and  internal  logical  subsystems 
(modules)  are  described  as  rectangular  boxes.  The  labels 
on  the  lines  connecting  the  boxes  represent  the  main 
information  flows  between  them.  Each  information  flow 
may  contain  several  levels  of  lower-level  flows  and 
information  items.  The  constituent  information  flows  are 
not  presented  graphically  for  the  sake  of  clarity,  but 
nevertheless,  they  are  an  integral  part  of  the  model. 
Lower  level  information  flows  can  be  observed,  for 
example,  by  making  queries  to  the  supporting  tool 
datab^.  Information  flows  may  represent  process  data 
flows  or  control  flows.  Information  flows  connect  the 
source  and  sink  of  the  information,  disregarding  its 
physical  routing  through  the  system.  It  must  be  stressed 
that  the  lines  connecting  the 


•  Surveillance,  e.g.  a  radar  or  an 
electro-optical  system 

•  Soft.Defense,  e.g.  an  electronic  warfare  system 

•  Weapon_Contiol 

•  Point_Defense_Missiles 

•  Point_Defense_Guns 

The  fimction  of  the  MPDS.Conirol  subsystem  (the 
"System  Controller”)  depicted  in  the  diagram  will  be 
explained  in  the  section  dealing  with  the  relationships 
between  the  conceptual  views.  Some  of  the  internal 
information  flows  are  also  shown  in  Figure  2.  The 
internal  information  flows,  “hidden"  inside  the  model 
provide  an  important  input  to  the  analysis  and  validation 
of  the  model’s  completeness  and  correctness. 

The  functional  capabilities  performed  by  the  system 
are  shown  in  Figure  3.  Some  of  the  functional 


logical  modules  do  not  represent 
hardware  signals  or  digital 
communication  paths  in  the 
system,  that  are  shown  in  the 
system’s  architectural  design 
diagrams. 

The  MPDS  environmental 
systems  shown  in  Figure  2  are 
systems  (external  to  the  MPDS) 
with  which  the  MPDS  system 
interacts.  These  systems  are: 

•  C^I  -  An  external  command 
and  control  system 

•  Targets  -  Unidentified 
targets  which  can  be 
classified  as  friendly  or 
hostile  or  can  remain 
unidentified 

•  Power_supply  -  An 
external  system  which 
supplies  electrical  and 
hydraulic  power  to  the 


Figure  3  -  MPDS  Functional  C^apabilities 
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(SR) 
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Ideiitify_Urgel 
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Contn>i_aim 
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success 
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U  pdate_lanet_track 

Solve_gdDC_eq>uiioas 

PR_laanch_check 

Evaiuaie_hit 

Guide.miuile 

Table  1  -  Sample  Capabilities  of  And  Missile  Point  Defense  Subsystems 


capabilities  of  the  subsystems  are  listed  in 
Table  1.  The  relationship  between  the 
capabilities  of  the  system  and  the 
capabilities  of  its  subsystems  are  described 
by  the  dynamic  proceisses  described  later 
on.  Since  the  logical  modules  are  active 
objects  [BOOC91],  the  functional 
capability  charts  always  include  a  control 
block  (MPDS.MODES  in  this  diagram). 
Its  function  is  to  control  the  order  in 
which  the  capabilities  are  activated,  as  will 
be  described  later  on. 


Some  of  the  functional  capabilities  of 
the  MPDS  are: 


MPDS_INIT 

Initialization 

MPDS_BIT 

Built-in  test 

MPDS_PARAMETER_SET 

SURVEEXANCE 


•  MPDS_PARAMETER_SET  -  Parameters  setting 

•  SURVEILLANCE  -  Surface  and  air 

surveillance 

•  ANTI_MISSILE_DEFENSE  -  Defense  against 

attacking  missiles 

The  two  diagram  types  represent  different  view  points 
on  the  system.  The  ^notional  capabilities  chart  shows 
the  activities  performed  by  the  system,  i.e.,  "what"  the 
system  is  doing,  while  the  logical  module  chart  describes 
the  conceptual  structure  (the  conceptual  "how")  of  the 
system  in  terms  of  logical  subsystems  or  building  blocks. 
The  use  of  logical  subsystems  in  ECSAM,  gives  it  its 
power  in  the  rapid  (tevelopment  of  system  models  and  the 
reuse  of  conceptual  models  of  various  subsystems. 


Figure  4  •  MPDS  Operating  Modes 


Modes  are  externally  visible  generalized  system 
states,  used  to  simplify  the  system  description  and 
analysis,  in  the  sense  described  by  [HENI80].  A  mode-by¬ 
mode  description  of  the  system  is  a  simple  way  to 
characterize  top  level  states  of  systems  as  seen  by  their 
operators  or  external  observers.  The  operating  modes 
concept  has  been  used  very  effectively  by  engineers  and 
operators  of  systems  for  many  years  in  various  Helds  of 
engineering.  Their  definition  in  the  initial  phases  of 
analysis  is  very  important  since  they  characterize  one  of 
the  sy^em’s  major  operating  features. 

Modes  and  the  transitions  between  them  can  be 
described  by  state  transition  diagrams.  In  their 
conventional  flat  form,  such  diagrams  typically  are  not 
structured,  do  not  support  the  concept  of  concurrency,  ate 
difficult  to  read,  and  are  not  easily  comprehensible  by  the 
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Figure  S  -  ECSAM  Process  Description 


system's  customers.  ECSAM 
alleviates  these  problems  by 
adopting  the  Statecharts 
approach,  developed  by  Harel 
while  consulting  for  lAI 
[HARE87].  Statecharts  employ 
the  notions  of  multi-level 
stmctive  (state  embedding),  levels 
of  detail,  and  the  2d>ility  to  split 
states  into  concunent  "and" 
components.  They  allow  the 
specification  of  concurrency, 
independence  and  synchronization 
in  various  ways  and  at  all  levels. 

The  advantages  of  using 
Statecharts  compared  with 
conventional  state  transition 
diagrams  are  discussed  by  Harel 
in  his  psq?er  [HARE87].  The  use 
of  Statecharts  has  become  a 
common  practice,  and  their 
syntax  and  semantics  won’t  be  elaborated  in  this  paper. 

The  main  operating  modes  of  the  MPDS  are  shown 
by  the  Statechart  in  Figure  4.  According  to  this  figure, 
die  system  can  be  in  the  “OCT  mode.  "Stand.By"  mode  or 
the  "MPDS_On"  mode.  When  in  the  “MPDS_On”  mode, 
the  system  can  be  in  the  “Operational"  or  “Simulation” 
mode  and  simultaneously  be  in  the  “Manual”  or 
“Automatic”  Mode. 

The  Dynamic  Process  View 

The  dynamic  process  view  describes  the  sequence  of 
op^tions.  within  each  functional  capability,  which  are 
activated  in  response  to  external  or  internal  events.  The 
dynamic  processes  describe  two  aspects  of  the  systems 
behavior  the  transformation  of  system's  inputs  to  its 
outputs  by  the  subsystem  capabilities  and  the  logic 
controlling  the  order  and  timing  of  the  activation  of  these 
capabilities. 

Each  dynamic  process  is  defined  graphically  by  two 
complementary  diagrams: 

1 .  The  process  DFD  (Data  Flow  Diagram),  describing 
the  fuiKtional  capabilities  participating  in  the  process 
and  the  data  flows  between  them.  It  also  contains  a 
control  capability  and  control  signals. 

2.  The  process  control  diagram,  describing  the  control 
capability  which  (tetermines  the  order  and  timing  in 
which  the  process  function.!  aq)abilities  are  activated. 
It  is  represented  by  a  Statechart 

Please  note  that  Statecharts  are  used  in  ECSAM  for 
two  distinct  purposes:  for  the  description  of  the  operating 
modes  and  the  transitions  between  them,  and  for  the 
description  of  control  of  the  dynamics  of  the  system 
processes. 


The  combined  use  of  the  {uocess  DFD  and  the  process 
control  diagram  to  describe  a  ]»tx:ess  is  (temonstrated  in 
the  simple  example  presented  in  Rgure  S. 

Two  functional  capabilities  (Capability.!  and 
Capability.!),  are  participating  in  the  process  in  the  DFD 
on  the  left-hmd  side  of  Hgure  S.  The  process  control  is 
described  by  the  Statechart  on  the  right-hand  side  of  the 
same  Figure.  The  participating  functional  capabilities  are 
performed  by  some  of  the  logical  subsystems  and  the 
control  of  the  process  is  performed  by  the  system 
controller. 

The  process  begins  in  the  Wait  state.  Following  the 
occurrence  of  Event.!  the  process  enters  State.!,  vhiile 
in  this  state  Capability.!  is  active.  The  correlation 
between  the  states  and  the  functional  capabilities  is 
represented  in  a  tabular  form  (and  not  gnqrhically)  as 
shown  in  Figure  S  and  later  on  in  the  example  descriM  in 
Table  2.  Upon  the  occurrence  of  the  internally  generated 
Event.2,  the  process  enters  State.2.  While  in  this  state 
Capability.2  is  actixe.  Following  the  occurrence  of 
Event.3.  depending  on  the  status  of  the  conditions  Cl, 
C2  and  C3.  the  process  reenters  State.!  or  the  Wait  state, 
or  is  terminated  as  marked  by  the  Encircled  T”  symbol. 

Analyzing  the  control  Statechart,  it  is  obvious  that  it 
describes  various  threads  of  dynamic  behavior,  depending 
on  the  order  of  occurrence  of  events  and  the  associated 
conditions.  The  description  presented  in  the  control 
Statechart  is  compact  in  the  sense  th?t  paths  which  can  be 
traversed  many  times  (repetitive  parts  or  parts  which 
belong  to  sever^  threads  of  dynamic  behavior)  are  "folded” 
upon  themselves,  and  are  presented  only  once. 

To  illustrate  the  power,  of  the  dynamic  process 
description  we  briefly  describe  a  simplified  version  of  the 
ANTI.MISSILE.DEFENSE  processes  of  the  MPDS. 
This  process  describes  the  dynamic  behavior  of  the  MPDS 
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Figure  6  -  MPDS  ANTI.MISSILE.DEFENSE 


functional  capability  Anti_Missile_Defense  speciHed  in 
Figure  3. 


Figure  6  describes  a  simplified  DFD  of  the  process 


iiKluding  the  control  signals.  The  functional  capabilities 
paiticii^ting  in  the  execution  of  this  process  are  a  subset 
of  the  functional  capabilities  of  the  MPDS  subsystems 
specified  in  Table  1.  The  diagram  is  a  conventional  DFD 
and  will  not  be  further  discussed  in  the  paper.  The 


Figure  7  -  MPDS  ANTI_MISSIIJS_DEFENSE  Process  Control 
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Table  2  -  Mapping  of  Anti  Missile  Defense  Process  Sample  Capabilities  to  States 
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Figure  8  •  ECS  AM  Computer  Based  System  Generic  Model 


corre^nding  simplified 
process  control  diagram 
is  described  by  the 
Statechart  shown  in 
Ingure  7. 

The  functional 
capabilities  of  the 
subsystems  activated  in 
each  of  the  process 
states,  correlating  the 
two  charts,  are  listed  in 
Table  2. 

The  dashed  AND 
line  in  Figure  7.  is  used 
to  denote  the  concurrent 
execution  of  capabilities 
in  a  process.  For 
example,  the 
Targetjrractog 
capability  of  the  WCS.  Soft.defense  capabilities  of  the 
EW,  and  defense  guns  preparation,  pointing  and  firing 
capabilities  of  the  PDG  are  performed  concurrently  with 
the  activities  performed  in  the  MISSILES.DEI^NSE 
state. 

Transitions  between  states  dictate  the  sequence  of 
execution  of  the  various  activities  of  the  sub-systems 
participating  in  the  process. 

Any  possible  thread  (scenario)  of  the  process  resulting 
from  a  random  combination  of  external  (and  internal) 
events  can  be  identified  and  analyzed. 

The  Relationships  Between  the  Conceptual  Views 

We  will  first  briefly  describe  the  ECSAM  generic 


model  of  computer  based  systems,  and  building  upon  it 
we  will  explain  the  relationships  between  the  conceptual 
views. 

We  assume  that  every  computer  based  system  and  aU 
of  its  subsystems  can  be  model^  as  a  hioarchical  amtrol 
system  according  to  the  generic  model  shown  in  Figure  8 
[LAV184], 

According  to  this  model  each  system  is  decomposed 
into  a  set  of  logical  subsystems  and  a  conceptual 
controller  which  controls  the  system’s  joint  operational 
behavior.  The  conceptual  controller  of  the  system 
presents  the  control  of  the  operating  modes  and  the  control 
of  the  dynamic  processes  discussed  earlier. 

Logical  subsystems  and  their  conceptual  controller 
can  be  further  decomposed  into  logical  subsystems  and  an 


Slatecharts  of  ail  system  dynamic  processes. 
The  conceptual  controller  may  include 
additional  functions,  e.g.,  the  handling  of  the 
control  signals  affecting  the  dynamic 
transitions  and  redundancy  management  of 
critical  systems. 

Processes  can  be  active  throughout  a 
mode  or  be  activated  by  events  while  being  in 
a  mode,  or  can  be  periodically  activated.  The 
controller’s  implementation  issues  are  treated 
during  the  system’s  design.  It  should  be 
stressed  that  the  services  of  the  conceptual 
system  controller  can  be  implemented  by  a 
centralized  controller  or  be  distributed  among 
many  subsystems. 


The  relationships  between  the  views  is 
formalized  in  Figure  10.  Figure  10-a  shows 
the  decomposition  of  a  system  into  its  logical 
subsystems.  The  functional  capabilities 
performed  by  each  subsystem  are  listed  in 
Table  a  in  Figure  10.  The  system's  overall 
capabilities  are  shown  in  Figure  lO-b.  Their 
activation  dqtends  on  the  mode  the  system  is 
in.  These  modes  are  shown  in  Rgure  10-c. 
Figure  9  -  ECSAM  Description  of  Multi-level  Systems  Each  of  the  system  capabilities  P(n)  is 

analyzed  as  a  process  described  by  the  two 
diagrams  shown  in  Figures  10-d  and  10-e. 
where  the  components  of  the  process  are  members  of  the 
set  listed  in  table  10-a.  This  is  shown  in  Rgure  10-d 
where  each  process  component  is  related  to  the  subsystem 
executing  it,  using  the  notation  M(k)>C(k.i).  i.e., 
capability  C(k,i)  is  performed  by  logical  subsystem  k. 
The  relationships  are  valid  for  each  logical  system  or 
subsystem  at  each  level  of  the  model  in  Figure  9.  The 
analysis  is  performed  iteratively  at  each  level  of  the 
model. 

It  is  important  to  stress  that 
the  nature  and  number  of  system 
processes  can  change  throughout 
the  system's  life  cycle.  However, 
once  we  have  properly 
decomposed  the  system  into 
logical  subsystems,  deHned  and 
implemented  their  functional 
capabilities,  we  can  always 
program  the  system  control  to 
execute  new  or  modified 
processes  using  the  basic 
subsystems’  capabilities 
implemented  by  the  system. 


External  Specifications 


Any  system  can  be  viewed  as 
a  part  of  a  higher-level  system. 
Practical  systems  can  be 
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Figure  10  -  Relationships  Between  ECSAM  Conceptual  Model  Components 


internal  controller  as  shown  in  Figure  9.  Naturally,  each 
of  the  subsystems  is  also  analyzed  using  the  three 
conceptual  views  discussed  earlier.  The  conceptual  system 
controller  (or  control  subsystem)  controls  the  joint 
behavior  of  the  subsystems’  functional  capabilities  by 
controlling  the  system’s  operational  modes  and  the 
dynamics  of  the  system  processes.  Its  functionality  is 
thus  defined  by  the  system  modes  Statechart.  and  by  the 
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embedded  in  various  environments,  such  as  their 
operational  environment,  maintenance  environment, 
testing  environment,  etc. 

Although  the  information  flows  between  the  system 
and  its  environment  may  be  similar  (such  as  in  the  case 
when  a  system  is  operated  in  its  operational  environment 
and  in  a  simulated  one),  the  environment  systems  may 
differ. 

ECSAM  provides  for  the  specification  and  analysis  of 
external  systems  containing  the  System  IJnder 
Development  In  such  cases,  the  SUD  may  be  viewed  as 
a  “plug-in”  component  used  in  various  ^plications. 


Several  different  models  describing  the  system  in 
various  environments  may  be  developed  for  a  SUD,  e.g. 
for  the  testing  and  integration  phase,  for  the  operation 
phase  and  for  the  maintenance  phase.  During  each  of 
these  phases  the  system  may  be  operated  in  a  different 
environment  and  consequently  the  speciflcations  of  the 
external  behavior  may  be  different.  In  Figure  II,  the 
MPDS  is  portrayed  in  its  operational  environment.  Other 
scenarios  may  require  the  definition  of  a  different,  suitable 
environment,  as  described  above.  The  analysis  of  the 
SUD  in  various  environments  can  contribute  considerably 
to  the  quality  of  the  design  and  the  analysis  of  the  SUD. 
The  recursive  nature  of  the  ECSAM  modeling  and 
analysis  methods  allows  the  use  of  the  very  same  generic 
models,  semantics  and  methods  in  each  level  of  a 
multilevel  system  analysis  irrespective  of  the  analysis 
level:  the  entire  system  or  any  of  its  lower-level 
subsystems. 


4.  The  ECSAM  Design  Model 

As  described  in  previous  sections,  the  conceptual 
model  helps  us  to  express  the  SUD’s  functionality,  and 
serves  as  a  vehicle  for  the  analysis  of  the  system's 
behavior  and  performance.  The  design  model  describe  the 
system's  architecture,  the  structure  of  its  hardware  and 
software  subsystems,  and  their  relationship.  It  also 
expresses  the  performance  and  implementation  constraints, 
and  describes  the  human  -  machine  interface. 

ECSAM  provides  a  set  of  rules  for  the  allocation  of 
capabilities  or  complete  logical  modules,  identified  within 

a  conceptual  model,  to  a 
design  model.  Such  a 
precise  mapping  is 
valuable,  since  it 
provides  traceability 
from  requirements  to 
design,  and  from  there  • 
to  implementation. 

Typically,  several 
different  design  models 
can  be  devised  for  any 
given  conceptual  model. 
This  characteristic 
provides  a  foundation  for 
the  reuse  of  generic 
conceptual  models  in 
diverse  implementations 
ILAV922].  The 
transition  from  a 
conceptual  model  to 
actual  design 
necessiuttes  the  addition . 
of  various  subsystems 
not  expressed  in  the 
conceptual  model  (e.g., 
interfaces,  communication  facilities).  These  additional 
subsystems  have  conceptual  models  of  their  own.  A 
design  model  usually  expresses  characteristics  originating 
in  several  conceptual  models. 

ECSAM’s  design  models  have  been  described  by  us 
in  detail  in  other  papers  [KUDI92,  LAV921]. 

5.  The  Analysis  and  Design  Process 

Years-long  engineering  experience  shows  that  the 
analysis  process  has  to  be  iterative,  and  that  several 
iterations  are  typically  needed  to  produce  a  good  final  set 
of  requirement  speciEcadons,  a  conceptual  model,  and  an 
architectural  view  of  the  design  model.  The  ECSAM 
method  supports  such  rtqtid  iterative  processes. 

ECSAM  mandates  the  analysis  of  each  layer  or  level 
of  the  system’s  conceptual  and  architectural  mt^ls,  and  of 
each  of  its  subsystems.  Omitting  the  analysis  of  any 
view  in  any  subsystem  will  result  in  incomplete  (and 
typically  even  incorrect)  specifications,  in  designs  that  do 


Figure  11  -  The  SUD  as  Part  of  the  Overall  System 


not  match  the  conceptual  model,  and  in  systems  that  do 
not  fully  answer  the  requirements.  At  lAl,  ail  information 
generated  during  the  iterative  ECSAM  process  is 
continuously  documented  and  cross  checked  using 
STATEMATE.  Brief  'ntermediate  documents,  which 
evolve  over  the  project’s  life-cycle,  are  automatically 
generated  to  support  the  iterative  process  and  its  Sequent 
internal  reviews. 

The  basic  ECSAM  method  analysis  steps  are  outlined 
below.  These  steps  are  applied  iteratively  in  the  analysis 
at  the  system  and  subsystem  levels.  A  full  description  of 
the  process  can  be  found  in  a  separate  report  [LAV921]. 
This  analysis  process,  proven  in  industrial  projects,  is 
also  regulvly  taught  in  ECSAM  courses  at  the  LAI. 

Description  of  the  ECSAM  Analysis  and  Design  Process 

The  ECSAM  analysis  and  design  process  consists  of 
13  main  steps: 

1.  Definition  of  the  system's  scope  and  external 
requirements 

1 . 1  Definition  of  the  system's  scope 

The  first  step  of  the  analysis  is  the  definition 
of  the  basic  scope  of  the  system  in  terms  of  its 
main  functions  and  basic  performance  criteria. 

1 .2  Processing  of  customer  requirements 

Concurrently  with  the  definition  of  the 
system's  scope  and  the  analysis  of  the  system  in 
its  environment  (step  2),  requirements  are  elicited 
from  various  applicable  documents.  These 
requirements  are  allocated  to  system  models’ 
components  after  completion  of  step  3,  and  they 
provide  a  foundation  for  the  design  and  testing  of 
the  system.  Requirements  management  and 
model  development  are  carried  out  iteratively 
throughout  the  development  cycle. 

2.  Definition  of  the  system  in  its  environment 

2.1  Preparation  of  the  “System  in  its 
Environment”  diagram 

The  boundaries  of  the  SUD  are  defined,  and 
environment  systems,  inputs,  and  outputs  are 
identified  and  described  in  a  diagram. 

2.2  Preparation  of  short  descriptions  of  the 
environmental  systems  and  flows 

The  environment  systems  are  briefly 
described,  and  so  are  the  information  flows 
between  the  system  and  its  environment. 

3.  Analysis  of  the  top  level  logical  modules,  internal 
information  flows,  and  capabilities 

3.1  Identification  of  logical  subsystems 
Given  the  scope  of  the  system,  a  basic  set  of 
requirements,  and  the  description  of  the  system  in 
its  environment,  it  is  possible  to  identify  the  top 


level  logical  subsystems,  and  their  major 
ciqKtbilities. 

The  initial  system  decomposition  is  based 
on  domain  knowMge  and  on  previous  knowledge 
and  experience  gained  in  the  development  of 
similar  systems  and  criteria,  outlined  in  other 
papers  [LAVI84,  LAVI891. 

3.2  Analysis  of  major  information  flows 

Major  system  outputs  and  major  system 

inputs  (needed  to  im)duce  the  major  outputs)  are 
ictentified.  Next,  the  paths  of  information  flows 
are  traced  through  the  previously  specified 
subsystems  or  modules  going  backward  fiom  the 
major  outputs  to  the  inputs. 

3.3  Identification  of  the  subsystems’ 

capabilities 

Each  of  the  logical  subsystems  is  next  drawn 
with  its  environment  on  a  separate  chart.  The 
logical  subsystem's  outputs  are  checked  to  verify 
the  ability  to  produce  them,  considering  the 
subsystem's  inputs  and  an  initial  set  of 
capabilities  for  each  subsystem  defined. 

4.  Initial  definition  of  the  system’s  basic  operating 
modes 

The  basic  operating  modes  of  the  system  are 
identified,  and  presented  using  the  Statecharts 
notation.  Valid  transitions,  and  the  events  and 
conditions  triggering  them  are  not  addressed  at 
this  step. 

5.  Definition  of  the  architectural  view  of  the  design 
model 

The  development  of  the  architectural  view  of 
the  design  model  requires  several  steps.  Initially, 
the  top  level  systems  architecture  is  defined.  At 
this  phase  the  design  involves  the  main 
architectural  modules  and  their  interconnections. 
To  do  so,  issues  such  as  the  architectural 
component  distribution,  coupling,  external  and 
internal  communications,  redundancies  and  HMI 
concepts  have  to  be  resolved,  based  on  a  chosen 
design  policy. 

6.  Identification  of  the  system's  external  specification 

The  external  specification  of  the  system 
relates  to  the  operational  requirements  of  the 
system.  It  is  usually  analyzed  jointly  by  the 
operators’  teams  of  the  user/customer  and  the 
d^lopeis. 

7.  Preparation  of  the  initial  top  level  system  specification 

Having  completed  the  above  steps,  an  initial 
top  level  specification  document,  which  includes 
definition  of  the  basic  physical  static  and 
dynamic  properties  of  the  system  is  generated. 


Questions  or  comments  on  content  should  be  directed  to: 


Dr.  Jonah  Z.  Lavi 
CBSE  Associates 
3  Tabenkin  St. 

Ramat-Qan,  Israel  52  302 

lavl@math.tau.ac.il 

972-3-571-8704 


Or  to: 


Grady  Campbell 

Software  Productivity  Consortium 
2214  Rock  Hill  Road 
Herndon,  VA  22070 
campbelg@software.org 
(703)  742-7104 


Send  feedback  on  the  Consortium's  Video  Program  and 
orders  for  video  products  to: 


Technology  TVansfer  Clearinghouse 
Software  Productivity  Consortium 
2214  Rock  Hill  Road 
Herndon,  VA  22070 
brewer@software.org 
(703)742-7211 


